1. About this document
2. Starting point
A project to add some more control to the PS5 Kerbal simulation.
After installing Kerbal on the PS5 and playing it for a while it quickly became clear that the controllers alone are not enough to enjoy the game. The search began to find some way of improving things. Kerbal allows control vi the PS5 controllers AND via keyboard and mouse. This means it should be possible to add some easy toggles/switches/rotary encoders to pass information to the game. The first switch would be the space bar which kerbal uses to trigger stages.
While this is being developed for Kerbal it is generally a keyboard and can just as easily be used for many other applications, including video conferences.
2.1. kerbal key bindings
The following is a list of key bindings we can work with.
2.2. Arduino - pro micro (5V)
Initial choice for a prototype is the AVR ATmega32u4 8-bit microcontroller which has a USB controller and can therefore be used as both a keyboard and mouse if required.
The Pro Micro is an Arduino-compatible microcontroller board developed under an open hardware license by Sparkfun. Clones of the Pro Micro are often used as a lower-cost alternative to a Teensy 2.0 as a basis for a DIY keyboard controller/converter when a lower number of pins would suffice.
2.3. WS2812 LEDs
Because it’s always good to have status LEDs an the WS2812 is one that is both easy to get and has good libraries with fastled and adafruit.
The fastled library looks like a good choice. The WS2812 LED rings I have are not tightly packed with LEDs but will suffice. As I have a few WS2812 strips on top of the one RGBW ring and a few WS2812 rings the choice went towards the WS2812 to be able to mix the strip and ring.
3. Step 1 - First prototype
To get started I went to an example for LEDs to be able to later set a LED with a key/button.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
#include <FastLED.h>
#define NUM_LEDS 22
#define NUM_RING_LEDS 12
#define DATA_PIN 7
CRGB leds[NUM_LEDS];
void setup() {
FastLED.addLeds<NEOPIXEL, DATA_PIN>(leds, NUM_LEDS);
leds[12] = CHSV(0, 255, 16);
leds[13] = CHSV(33, 255, 16);
leds[14] = CHSV(65, 255, 16);
leds[15] = CHSV(97, 255, 16);
leds[16] = CHSV(129, 255, 16);
leds[17] = CHSV(161, 255, 16);
leds[18] = CHSV(193, 255, 16);
leds[19] = CHSV(225, 255, 16);
leds[20] = CHSV(255, 255, 16);
leds[21] = CHSV(255, 255, 16);
FastLED.show();
}
void loop() {
for(int dot = 0; dot < NUM_RING_LEDS; dot++) {
leds[dot] = CHSV(64, 255, 16);
FastLED.show();
// clear this led for the next time around the loop
leds[dot] = CRGB::Black;
delay(150);
}
}
|
The first test looks good and was tested on a 5v pro micro. The prototype uses a strip with ten LEDs attached to a ring with 12 LEDs. |
The above code runs a LED around the ring and sets static colours on the strip. A good start. The animation works with delay which is probably not a good solution but works fine for a first test.
4. Step 2 - Attach a button to trigger a stage
Since this will be starting rockets let’s make it feel that way. Just the space bar and maybe a toggle to arm it.
-
keyboard
-
Button
-
State change detection
We will need to pull down/up the pin for the button so the above resistor is included to show an example 10K Ohm resistor.
The big red button is to trigger a stage and the toggle switch is to arm it.
4.1. Bouncy Bouncy
Why all the fuss about bounce? And what is it?
4.1.1. Interrupts
The Pro Micro has five external interrupts, which allow you to instantly trigger a function when a pin goes either high or low (or both). If you attach an interrupt to an interrupt-enabled pin, you’ll need to know the specific interrupt that pin triggers: pin 3 maps to interrupt 0 (INT0), pin 2 is interrupt 1 (INT1), pin 0 is interrupt 2 (INT2), pin 1 is interrupt 3 (INT3), and pin 7 is interrupt 4 (INT6).
pro micro hookup guide
1
2
3
4
5
6
7
8
9
10
11
void my_interrupt_handler()
{
static unsigned long last_interrupt_time = 0;
unsigned long interrupt_time = millis();
// If interrupts come faster than 200ms, assume it's a bounce and ignore
if (interrupt_time - last_interrupt_time > 200)
{
... do your thing
}
last_interrupt_time = interrupt_time;
}
The above short section shows a debounced interrupt that uses millis instead of delays. The important thing here is that if we debounce with delays we stall the whole loop so that if we have a LED animation or something else running it get’s stalled. Using millis allows the rest to keep running.
Let’s see if some of the above works.
4.2. first iteration
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
const int buttonPin = 9;
const int ledPin = 13;
int ledState = HIGH;
int buttonState;
int lastButtonState = LOW;
unsigned long lastDebounceTime = 0;
unsigned long debounceDelay = 50;
void setup() {
pinMode(buttonPin, INPUT_PULLUP);
pinMode(ledPin, OUTPUT);
digitalWrite(ledPin, ledState);
}
void loop() {
int reading = digitalRead(buttonPin);
if (reading != lastButtonState) {
lastDebounceTime = millis();
}
if ((millis() - lastDebounceTime) > debounceDelay) {
if (reading != buttonState) {
buttonState = reading;
if (buttonState == HIGH) {
ledState = !ledState;
}
}
}
digitalWrite(ledPin, ledState);
lastButtonState = reading;
}
|
The first test looks good and was tested on an arduino UNO. |
The above code works as a debounced latching button. The aim though is to read a debounced button and to read it’s state changes.
-
ONLY when the button is pressed
-
output state ONCE
-
-
When button is released
-
Output state once
-
4.3. Second iteration
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
const int buttonPin = 9;
const int ledPin = LED_BUILTIN;
//start with led OFF
int ledState = LOW;
int buttonState;
//unpressed is assumd
int lastButtonState;
unsigned long lastDebounceTime = 0;
unsigned long debounceDelay = 50;
void setup() {
//default unpressed=HIGH
pinMode(buttonPin, INPUT_PULLUP);
pinMode(ledPin, OUTPUT);
Serial.begin(115200);
digitalWrite(ledPin, ledState);
int buttonState = digitalRead(buttonPin);
lastButtonState=buttonState;
Serial.println("setup complete");
Serial.print("Button is ");
Serial.println(buttonState);
}
void loop() {
int reading = digitalRead(buttonPin);
if (reading != lastButtonState) {
lastDebounceTime = millis();
}
if ((millis() - lastDebounceTime) > debounceDelay) {
if (reading != buttonState) {
buttonState = reading;
Serial.println("transition");
if (buttonState == LOW ) {
Serial.println("ARMED");
ledState = LOW;
}
else {
Serial.println("DISARMED");
ledState = HIGH;
}
}
}
digitalWrite(ledPin,ledState);
lastButtonState = reading;
}
|
This works and it was tested on an arduino uno. Serial monitor was used to check the function. |
5. Step 3 - bring things together to see how the loop runs with buttons
|
Work in Progress |
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
#include <FastLED.h>
//fastled stuff
#define NUM_LEDS 22
#define NUM_RING_LEDS 12
#define DATA_PIN 7
#define disarmed_LED 12
#define armed_LED 13
#define SAS_LED 14
#define rot1p_LED 15
#define rot1m_LED 16
#define rot1b_LED 17
CRGB leds[NUM_LEDS];
//button stuff
const int buttonPin = 8;
const int ledPin = LED_BUILTIN;
//start with led OFF
int ledState = LOW;
int buttonState;
//unpressed is assumd
int lastButtonState;
unsigned long lastDebounceTime = 0;
unsigned long debounceDelay = 5;
void setup() {
//LED stuff
FastLED.addLeds<NEOPIXEL, DATA_PIN>(leds, NUM_LEDS);
leds[disarmed_LED] = CRGB::Red;
leds[armed_LED] = CRGB::Black;
leds[SAS_LED] = CRGB::Black
leds[rot1p_LED] = CRGB::Black
leds[rot1m_LED] = CRGB::Black;
leds[rot1b_LED] = CRGB::Black;
//spare
leds[18] = CHSV(0, 255, 16);
leds[19] = CHSV(63, 255, 16);
leds[20] = CHSV(127, 255, 16);
leds[21] = CHSV(255, 255, 16);
//END LEDS
FastLED.show();
//button stuff
//default unpressed=HIGH
pinMode(buttonPin, INPUT_PULLUP);
pinMode(ledPin, OUTPUT);
digitalWrite(ledPin, ledState);
int buttonState = digitalRead(buttonPin);
lastButtonState=buttonState;
//The rest
Serial.begin(115200);
Serial.println("setup complete");
}
void loop() {
for(int dot = 0; dot < NUM_RING_LEDS; dot++) {
leds[dot] = CHSV(64, 255, 16);
FastLED.show();
// clear this led for the next time around the loop
leds[dot] = CRGB::Black;
delay(150);
}
}
6. Step 4 - rotary encoders
Appendix A: Requirements
-
Control Kerbal on PS5
-
Via USB(A) keyboard interface
-
Use big red button with latch for stages
-
-
Must show actions/button presses
-
WS2812 for key status changes red/green/etc
-
-
Add some safety toggles (arm/disarm)
-
A classic toggle with red cover
-
-
Control
-
Stage trigger (space bar)
-
SAS (on/off) (t)
-
gear (up/down) (g)
-
time warp (rotary +/-) (.,)
-
throttle (rotary +/-) (shift,cntrl)
-
motors (on/off) (x,k)
-
View (inside/outside) ???
-
-
This should cover the most required buttons and should be possible without multiplexing.
Appendix B: Interface design thoughts
Since the first button is a big red one with a latch it make sense to also show what state it’s in. Adding a LED ring around it sounds like a good idea. Adding a LED ring around a rotary encoder also sounds like a good idea (optional).
B.1. Arm/disarm toggle
- toggle disarmed
-
disArm led LED red(?), latch ring red blink(?)
- toggle armed
-
ARM led green, latch ring green
B.2. Triger stage button
- unlatched
-
ring green
- press
-
ring red for 1 sec
- latched
-
Ring orange
Appendix C: 3d printed test stand
The Aim here is to have a stand to mount the buttons and LEDs to while testing. After testing this can be used as a template for drilling. Also this can later be adapted to make a holder for the led ring and potentially the leds that can be mounted under the lid of the box.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
$fn=360;
// mm for slyrs box
topWidth=117;
topDepth=106;
topThick=2;
pillar=4;
height=46;
BigRedButtonD=22;
ToggleD=12;
WS2812D=4;
WS2812RingR=42/2;
numLEDs=12;
//versioning
letter_size = 10;
letter_height = topThick/2;
font = "Liberation Sans";
Version = "V3" ;
module letter(l) {
linear_extrude(height = letter_height) {
text(l, size = letter_size, font = font, halign = "center", valign = "center", $fn = 16);
}
}
module legs() {
//Legs are only needed during prototype phase
translate([0,0,0]) cube([pillar,pillar,height]);
translate([topWidth-pillar,0,0]) cube([pillar,pillar,height]);
translate([topWidth-pillar,topDepth-pillar,0]) cube([pillar,pillar,height]);
translate([0,topDepth-pillar,0]) cube([pillar,pillar,height]);
}
module boxTop() {
cube([topWidth,topDepth,topThick]);
}
module bigRedButton() {
// Big red Button
cylinder(h=topThick+2,d=BigRedButtonD);
}
module toggleSwitch() {
// toggle switch
cylinder(h=topThick+2,d=ToggleD);
}
module cherryKey() {
// toggle switch
cherryKeycap=18;
cherryClearance=cherryKeycap+1;
cylinder(h=topThick+2,d=cherryClearance);
}
module LED() {
// disarmed LED
cylinder(h=topThick+2,d=WS2812D);
}
module LEDRing() {
//LED ring
for ( i = [0 : 360/numLEDs : 360] ){
rotate([0, 0, i]) translate([0, WS2812RingR, -1]) LED();
}
}
module versioning() {
//text
letter(Version);
}
module testStand() {
legs();
translate([0,0,height])
difference() {
boxTop();
translate([topWidth/2,topDepth/2,-1]) bigRedButton();
translate([topWidth/6,topDepth/2-6,-1]) toggleSwitch();
translate([topWidth/6,topDepth/4,-1]) LED();
translate([topWidth/6,topDepth/4-10,-1]) LED();
//3 keys with circular keycaps chery MX clones
//keycaps have text on caps
translate([topWidth*.25,topDepth-(19/2)-7,-1]) cherryKey();
translate([topWidth*.5,topDepth-(19/2)-7,-1]) cherryKey();
translate([topWidth*.75,topDepth-(19/2)-7,-1]) cherryKey();
translate([topWidth/2,topDepth/2,0]) LEDRing();
translate([topWidth/2-10,+10,(topThick/2)+.5]) versioning();
}
}
testStand();
//add a right side with holes for rotary encoders or wait?
// wait?
// the side will have two rotary encoders
// one for Throttle and one for timewarp
// add Leds on the top ( + / toggle-Key / - )
// 3 LEDS for each encoder
module ringHolder() {
//module for led ring holder - DRAFT
holderH=2;
holderOutD=50;
holderInD=35;
holderFence=1;
holderFenceOutD=holderOutD+holderFence;
holderFenceInD=holderInD-holderFence;
difference() {
//holder ring
difference () {
cylinder(h=holderH+holderFence,d=holderFenceOutD);
translate([0,0,-1]) cylinder(h=holderH+holderFence+2,d=holderFenceInD);
}
//led ring for subtraction
translate([0,0,holderFence+1]) difference () {
cylinder(h=holderH,d=holderOutD);
translate([0,0,-1]) cylinder(h=holderH+2,d=holderInD);
}
}
}
//draft for now
//ringHolder();
//LEDRing();
The first test fitting worked well to show up some room for improvement:
-
Toggle switch moved left and down
-
legs longer
-
LED ring proper Radius
The intial V2 print populated with additional key caps placed to show approximate position of possible keys for later.
Appendix D: openscad library for custom keycaps
the following library allows the creation of keycaps in different sizes and shapes. since we’ll be drilling the holes for any buttons round keycaps for cherry mx switches looks like a good option for keys.
As there is a broken backlit keyboard lying around it will probably find itself devoid of some switches for this if they fit.
The above keycaps fit the MX clone switches we have and will work for prototyping. To make them look like really high quality switches some post processing will be required. This was a quick and dirty print in low resolution for initial testing.
-
One variant might be to print Caps with no inlay
-
Sand with 1000+ grit
-
Paint
-
Cover with tape
-
Laser inlay through tape
-
Paint inlay
-
Remove tape
-
-
Another variant might be to print in the target colour with inlay
-
Paint inlay
-
Sand with 1000+ grit
-
The above approaches need to be tested but since printing key caps is easy enough now this also should be easy enough. It might involve printing a positioning guide to help align any laser cutting and that can be done at a later stage if required.
From this initial very fast test it looks like the laser option is getting more likely. Because the keycap is sloped the sanding uncovers the slope lines and, because we’re hand sanding, unevenly. This leaves a slight artefact that would ideally beg for a coat of paint which would cover the inlay again so the simple sand - paint - sand option doesn’t look that good. The painted part did look good though even if it didn’t have time to dry. One question is what will the laser do with PLA. One question though is answered: The inlay looks good and sanding works well if combined with paint.
PLA doesn’t look that nice when sanded. The result of heat to the above key, while not shown, was uneven and unsatisfactory an probably requires more skill to do well so that the 2 minutes spent might have turned something better up if they had been 15 minutes. Still the result of the 2 minutes with a gas torch showed that the layer lines will be highlighted through heating so that it probably only makes good sense for a flat surface or one with finer layer lines more closely spaced. There is probably room for experiments with solvents here also as others have had success with that. The laser option looks to probsbly be the one with a higher degree of repeatability and probably a better surface finish also through sanding and painting and sanding and painting and then lasering though tape and filling in the inlay with the tape in place. The laser will require some help with positioning so a printed MX key stalk on a positioning plate for a wainlux K6 laser will probably be designed and printed to assist as otherwise the sloped keys are likely to be misaligned through rotation more than X/Y position. Maybe something like this: https://www.thingiverse.com/thing:4718186